This invention relates to the fields of software and computer systems. More particularly, a system and methods are provided for managing a multi-component software installation.
Many software products are distributed in component form. Instead of a single parcel that includes all program functionality, a component-based software product comprises multiple components having different functionality. Functionality of the different modules may or may not overlap or complement each other.
This type of configuration is particularly common among suites of business software, which may offer separate components for different aspects of a business, such as: point-of-sale, invoicing, inventory, billing, accounting, payroll, etc. Different customers having different needs may purchase different permutations of a given multi-component software product, based on their individual needs.
Because the components are part of one software product, they may be configured to take advantage of other components that are available in the same computer system. Thus, if an inventory component is installed, during execution it may be automatically updated based on activity within a point-of-sale component and/or some other module. Without the inventory component, the inventory functionality may have to be performed manually or with some other software.
Existing component-based software products tend to suffer from various shortcomings, such as the inability to dynamically detect the presence of a complementary component and make use of it, while still functioning properly if that complementary component is not installed. In particular, some multi-component software products do not provide any means, or any efficient means, for automatically determining—during installation of one component—which (if any) other components are installed.
Even if this information is available, it may not be updated when one component changes (e.g., is updated or uninstalled). If connections between components are not made and broken automatically (e.g., as components are installed or uninstalled), then the customer (or some other party) may need to manage the connections manually.
Another problem in some installations is that a customer may be able to identify components that it has not purchased. For example, the installation may place a catalog or list of all product components on the customer's system, possibly to allow the installer to identify which components are already installed so that the software can create the necessary connections. The vendor of the multi-component software may prefer that customers not be able to detect, based on their product configuration, what other components are available.
Yet another problem lies in the desire for graceful degradation of the software if one component is uninstalled or altered (e.g., to turn off some functionality). If the software environment does not automatically detect this change and alter the connections between components as necessary (e.g., to avoid calling a component that no longer offers functionality that it had previously), the whole product may fail or exhibit poor performance.